On 22nd October 2009 Microsoft released Windows Server 2008 R2 and Windows 7; PowerShell, version 2.0 was included as a part of that release. PowerShell version 1.0 had shipped a few years earlier during November 2006 at ITForum in Barcelona. So what has changed during those three years, how has the product matured and why would the regular systems administrator or database administrator care?

In this article I will highlight the ten most important reasons why this should be important to you, whether you had a previous interest in Windows PowerShell or not.

1) It’s in the Operating System!

The previous version of Windows PowerShell, 1.0, was a separate download which could be installed on Windows operating systems from Windows XP for clients and Windows Server 2003 for servers and later. This meant potentially a lot of work to make it available throughout an organisation, not just technically to deploy it, but also the likelihood that a systems administrator may need to justify to various parts of the organisation why they need to deploy; in other words a potential barrier to adoption. Sometime after the release of the individual downloads for the various versions of the Windows operating systems, Windows PowerShell 1.0 was made available via Windows Update. This gave the possibility for customers using either Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) an easier method for deployment; however they still potentially had non-technical hurdles to clear.

In addition, PowerShell 1.0 required the .NET Framework version 2.0 to be installed first. This was not included as part of Windows Server 2003 or Windows XP, so again potentially an extra install and more questions to answer along the lines of “Why do we need this again?”.

With the initial release of Windows Server 2008, PowerShell 1.0 was made available to install as a Feature, so that was a step in the right direction of being easier to install, however it was not installed by default.

Fig 1. – Install PowerShell 1.0 as a Feature in Windows Server 2008

With the release of Windows Server 2008 R2 and Windows 7, PowerShell 2.0 is included as part of the operating system by default. There are no downloads required, no installation wizards to complete and no managers to convince as to why it should be installed – it’s already there!

In fact, PowerShell is becoming such a fundamental part of Windows administration that in Windows Server 2008 R2 PowerShell has even made it onto the Start Bar.

Fig 2. – PowerShell 2.0 icon on the Windows Server 2008 R2 Start Bar

Another important step forward with the release of Windows Server 2008 R2 is that it is now possible to install PowerShell 2.0 on top of the Server Core installation option of Windows Server. In case you are unaware, since Windows Server 2008 it has been possible during installation of the operating system to choose Server Core as an option; this is a cut down version of Windows Server with no GUI. The primary aim with Server Core is to provide a version of Windows Server with a minimum installation for particular server roles, consequently reducing the attack surface and levels of patching which are required.

Only specific roles such as Active Directory or DHCP were available in Server Core for the initial release of Windows Server 2008. One item missing was the .NET Framework which, since it is a requirement for PowerShell, meant that it was not supported to run PowerShell on Server Core systems. Now in Windows Server 2008 R2 selected portions of the .NET Framework have been made available for the Server Core option; consequently it is possible to install PowerShell 2.0. It is important to mention that it is not installed by default in Server Core, however this is a natural consequence of a modular based operating system – only the required components are installed.

2) 100+ New Cmdlets

PowerShell 1.0 shipped with over 100 cmdlets which were available to any user out of the box. With the release of PowerShell version 2.0 another 100+ cmdlets were introduced as standard. These range from new groupings of cmdlets to provide specific new features and functionality to single cmdlets to make the systems administrator’s life slightly easier in many different places.

One of the goals of the PowerShell product team when improving PowerShell between versions 1.0 and 2.0 was to make lots of small improvements in addition to the more publicised new features. In this blog post Jeffrey Snover, Distinguished Engineer and leader of the PowerShell team, describes how they aimed to make 1000 things 1% better.

For example, PowerShell version 2.0 contains a new cmdlet Get-Random, which amongst other things can generate random numbers. Let’s use Get-Random to generate a random number between 1 and 10:

Fig 3. – Generating a random number with Get-Random

Pretty simple you will agree. How could you have done this in PowerShell version 1.0 without the Get-Random cmdlet? Well you could have used some .NET code, for instance:

Fig 4. – Generating a random number with New-Object System.Random

Will it save you hours of time? No. Will it make your life for that one particular task just that little bit easier? It might well do. Will hundreds of these smaller improvements make you feel happier about your experience with PowerShell? Quite likely so.

If you want to find out more about what new cmdlets are available and examples of how they might be used, you can check out my blog series, PowerShell 2.0: One Cmdlet at a Time, where I have gone through each new cmdlet.

3) Remoting

One of the most frequently requested improvements to PowerShell 1.0 was the ability to run all of the fantastic newly-available cmdlets against remote systems. Whilst there was one major cmdlet, Get-WMIObject, which had built-in remoting capabilities and there were some workaround possibilities, such as third-party products, generally the remoting story was not a great one. In PowerShell 2.0 there are thirty-five standard cmdlets which feature built-in remoting capabilities and, most importantly, you can run any PowerShell cmdlet on a remote Windows system after first establishing a remote connection to that machine utilising Windows Remote Management (WinRM).

In a previous article for Simple-Talk I covered in detail the various parts of remoting work and what needs to be done to make it available. Consequently I won’t go into detail here, however it is important to know that it is a major step forward from the previous release and opens up so many more possibilities for remote management of Windows systems.

4) Integrated Scripting Environment (ISE)

With PowerShell version 1.0, the systems administrator worked either from the familiar blue console or they were writing scripts in a third-party editor such as PowerGUI, PowerShell Plus or PrimalScript. With the release of PowerShell version 2.0 a new tool, the Integrated Scripting Environment (ISE), is included by default. With the ISE, it is possible to work both in a console style, with much nicer features than the standard console, and edit scripts in one tool.

The tool is split into three sections, as seen in the below figure. An Editor Pane for writing scripts, a Command Pane area for entering interactive commands and the Output Pane for displaying output either from executed scripts or interactive commands.

Fig 5. – PowerShell ISE components

Some of the main benefits of the PowerShell ISE are:

• Syntax highlighting within scripts and the console
• Multiple tabs for script editing
• Easier copy and paste than the standard console
• Multiple console tabs
• F1 style help for cmdlets

Fig 6. – Syntax highlighting within scripts and the console

Fig 7. – Multiple tabs for script editing

Fig 8. – Easier Copy and Paste than the standard console

Fig 9. – Multiple console tabs

Fig 10. – F1 style help for cmdlets

These features are available out of the box, so whilst a systems administrator might have a third-party editor for writing scripts on their own workstation, that tool would not likely be available throughout the organisation. If there was a need say to make some quick minor changes to a script residing on a server then it could be opened within the PowerShell ISE and features such as syntax highlighting would be available. Previously, Notepad might have been used, which despite its many uses over the years, can’t compete with a tool like this for features.

It is also possible to customise the PowerShell ISE and the way to do it is using PowerShell code! Doing so is beyond the scope of this brief introduction, but checking out the variable $psISE and the options property would be a good starting point.

Fig 11. – $psISE

Fig 12. – $psISE.Options

5) Jobs

PowerShell version 2.0 introduces the concept of ‘jobs’. In the previous version when a command was submitted at the console, the prompt was not returned to the user until that command had completed. Whilst this may not be a problem for commands which complete quickly, it could be an issue for those that are say retrieving large amounts of data or making changes to multiple remote machines. By utilising ‘jobs’, it is possible to submit a command, or sets of commands, as a job. Once submitted control of the console is returned to the user and the results of the submitted job can be retrieved later. Let’s look at an example:

Imagine that we wanted to return all of the directories in the C:\Program Files folder, this could take some time and we might want to get on with something else in the meantime. The below code would get the required results:

Instead, let’s submit that as a job and collect the results later:

We can check on the status of jobs we have submitted with the Get-Job cmdlet. Notice the State is Running.

Fig 13. – Details of a running job

Once finished, the State will change to Completed.

Fig 14. – A completed job

Now that the job has finished, it is possible to go and collect the results with the Receive-Job cmdlet. The default behaviour of Receive-Job is to remove results when retrieving them, so we will use the -Keep parameter to leave them available for subsequent retrieval if necessary.

Now if we look at the Count property of the results we have returned we can see that there are 201 directories in C:\Program Files on this machine:

Fig 15. – Count property of the results from the submitted job.

This was a very simple example; however it is not difficult to imagine how it would be possible to extend this to more complex tasks. It is also worth noting that some cmdlets in PowerShell version 2 have a -Job parameter, so it is possible to submit a job directly from the cmdlet itself. For example, to submit a ping test to both Server1 and Server2 as a job, execute the below.

To help find which cmdlets which can submit a job directly, use the below command to retrieve a list of cmdlets with the -Job parameter:

Fig 16. – Cmdlets with a -Job parameter

6) New Operators

The marketing people may not think it is a big feature, but it makes everyday life working at the command line, or writing scripts, that little bit easier. PowerShell 2.0 introduces three new operators: Split, Join and Splat (what a great name!)

For Split and Join think the Split and Join methods of System Strings, but now as operators. For example to split the below strings using a comma to distinguish them, use the below:

Fig 17. – Splitting strings

Conversely, to join the three strings together:

Fig 18. – Joining strings

Splatting allows the administrator to specify parameters and values in a hash-table and then supply the hash-table to be used in a cmdlet. We use the @ sign to do this. For example, firstly create a hash-table with a parameter of Name and values of a* and s*.

Fig 19. – Splat hash table

Now use the Get-Service cmdlet to retrieve all services beginning with an ‘a’ or an ‘s’.

Fig 20. – Using splatting to retrieve services beginning with an ‘a’ or an ‘s’.

Obviously, that was a very simple example, but you can imagine the possibilities for invoking cmdlets with multiple values supplied from a hash table.

7) Modules

In PowerShell version 1.0, it was quite a task  to supply additional cmdlets to the user. They had to be packaged up into what is known as a ‘snapin’ and installed on the user’s system, typically from an MSI install. In version 2.0 Modules are essentially the evolution of snapins and it is now possible for the System Administrator or DBA to provide this kind of functionality for other users. No longer is there a need to create dlls: Instead,  a module can be created and shared simply as a script with functions in it.

The environment variable $PSModulePath lists the location where PowerShell will look for modules, by default it is the two locations below:

Fig 21. – Default paths for modules

For example let’s turn the following function into a module.

To create a Maths module, you can simply create a folder Maths in a default module path and copy the function above into a file Maths.psm1 . That’s right, all that needs to be done to create a module is to save functons, which typically would have been in a standard PowerShell script *.ps1 file, into a *.psm1 file! (It is possible to make things more complicated, but that’s for another article).

Fig 22. – The Maths module

The cmdlet Get-Module with the -ListAvailable parameter confirms that the Maths module is potentially available to use.

Fig 23. – Available modules

To use the module we execute the Import-Module cmdlet with the name of the module Maths and the -PassThru parameter just to expose the output of this command to the screen.

Fig 24. – Import the Maths module

Now the Squared function is available for use:

We could now add many other mathematical functions to the Maths module and easily distribute all those functions to other users.

8) Bundled Modules in Windows Server 2008 R2

As mentioned in section 6, the introduction of modules makes it easier for the Systems Administrator or DBA to create and distribute re-usable code for themself or others. The use of bundled modules makes it even easier. This is  the mechanism whereby Microsoft is distributing additional cmdlets for the manageability of their product base. For instance, in Windows Server 2008 R2 there are many components which newly feature built in PowerShell support and the method to access them is typically by using Import-Module. A sample of these Windows Server Roles with PowerShell support is listed below, for the full list follow the subsequent link. I think if you are a Windows focused systems administrator it’s pretty likely that you are going to touch one or more of these areas.

• Active Directory
• Group Policy
• IIS
• Remote Desktop Services
• Failover Clustering
• Network Load Balancing

http://technet.microsoft.com/en-us/library/ee308287%28WS.10%29.aspx#BKMK_Appendix

Previous versions of Windows Server typically only had PowerShell support for these roles via third-party products. Now it’s available from the OS and the sooner you start getting to grips with it the better – you want to be better at your job don’t you?

9) Third-Party Vendors

When PowerShell 1.0 first shipped a number of third-party software vendors quickly jumped on the bandwagon and released various sets of PowerShell cmdlets and toolkits. Some, like Quest with the Active Directory cmdlets, to plug gaps in Microsoft’s coverage of their own products; others like PowerGadgets from SoftwareFX, to extend the built-in functionality of PowerShell.

However, after the initial buzz things went a little quieter for a while. That is until PowerShell 2.0 was released and now they seem to be coming from everywhere! Very few systems administrators work in an entirely Microsoft software based organisations and typically most need to be multi-skilled across many vendors’ software. Wouldn’t it be great if the systems administrator only needed to learn one scripting language to manage the different environments they were responsible for? How about combining elements from different technologies in the same script? Well if they manage any of the below technologies, then it is possible.

• VMware vSphere Virtualisation. One of the early supporters of PowerShell via what was known as the VI toolkit, and is now known as PowerCLI. PowerCLI has become incredibly popular with VMware administrators and new versions now typically ship in line with vSphere releases. In a previous article for Simple-Talk I explained how to get started with PowerCLI.
• Citrix XenApp 6. Another product which typically has a large cross-over with Windows administrators and has recently deprecated the long time MFCOM interface used by scripters and developers in favour of a PowerShell SDK. There are also PowerShell cmdlets for Citrix XenServer
• Not just Windows systems. Work with Red Hat Enterprise Virtualization Manager? Then there are PowerShell cmdlets.
• Maybe the admins work with storage hardware, not just software? Well NetApp have released a PowerShell toolkit for managing their storage. The interesting thing about this toolkit from a development point of view is that it took one engineer only three months to write 350 cmdlets!
• Or what about managing Intel vPro Processors with their recently released PowerShell module?

If your software / hardware vendor of choice is not shipping a PowerShell toolkit, and you need one, then tell them you want it!

10)Exchange and SharePoint 2010

OK, not a point specifically about PowerShell 2.0 itself, but did I tell you Exchange 2010 ships with 638 cmdlets and SharePoint 2010 with 492?! If you’ve read this far then you probably don’t need any more convincing.

Summary

PowerShell 2.0 brings a lot to the table; with new cmdlets, enhancements to existing cmdlets and new features such as remoting, jobs and the ISE. However, it’s possibly the impact of becoming part of the OS, the numerous modules included as part of Windows 2008 R2, the hundreds of cmdlets shipping with products like Exchange and SharePoint and the rapidly growing PowerShell toolkits from third-party vendors which is making it a must for every systems administrator’s toolkit.